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•§. 



Overview 



History of DNS and the Kaminsky attack 
Various DNS problems explained 
Where to address the DNS problem 

- Nameservers, Network, Client and Data 
Bad ideas and why we won't do them 
Proposed and implemented ideas 
The future of DNS(SEC?) 
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Sunday August 17 , -Q0£ 



DNSCurve will save the day 

Bernstein said that time on breakable 

DNSSEC offers "a patches," Bernstein said, 

surprisingly law level of He called for development 

security" -while causing of DNSSEC alternatives 

severe problems for DNS that quickly and securely 
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Connecting Networks and People 
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OpenDNS 



ISC )( Internet Systems Consortia 
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Two phase deployment 



First release a generic fix for the 
Kaminsky attack that does not leak 
information to the bad guys (source 
port randomization) 

Then release the bug and patches 
specifically against the Kaminsky 
attack 
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DNS query packet 



IP header containing Source IP and Dest IP 



UDP or TCP Header containing 

Source Port and Dest Port 

(if TCP, also random Sequence Number) 

DNS Query ID 
DNS Query 
Option flags 



] 
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DNS query example 



12.110.110.204 



193.110. 157. 13f 




DNS Query ID: 54321 

DNS Question: www.ripe.net? 

Option flags: RD 
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DNS An swer packet 

12.110.110.204 



193.110.157.136 



UDP:53 



12345 



QUESTION SECTION 
Query ID: 54321 
Question: www.ripe.net? 



ANSWER SECTION 



AUTHORITY SECTION 

ripe.net NS ns-pri. ripe. net. (ttl = 172800) 

ripe.net NS ns-ext. isc.org. (ttl = 172800) 

ADDITIONAL SECTION 

ns-pri. ripe. net A 193.0.0.195 (ttl = . 

ns-pri. ripe. net AAAA 2001:610:240:0:53:3 
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- TX 



XID is not enough anymore 



Bellowin's (theoretical) attack (1995) 



4 



Q:google.com 
► 



Na 

A:1.2.3.4 

src port: 53 

TXID: 15824 

Al.2.3.4 

src port: 53 

TXID: 37563 



erver 




Q:google.com 

src port: 53 

TXID: 12963 



A:1.2.3.4 

src port: 53 

TXID: 23221 



EVIL 
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nsl.google.com 
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* 



Losing the race 






ISPNS EVIL 

- Q:www. rbc.com ? 



RBCNS 



Q: www. rbc.com ? 7a ID = 32768 



A: www.rbc.com = 1.2.3.4; TXID = 00001 
i A: www.rbc.com = 1 .2.3.4 ; TXID = 00002 



A: www.rbc.com = 1.2.3.4; TXID = 00003 



A: WWW.rbC.com = 142.254.1 .143 ; TXID = 32768 



A: www.rbc.com = 
142.254.1.143 



TTL=86400 



TIME 
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Winning the race 
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Fnrilkpr lOr NO 




EVIL 




RBCNS 





Q:www. rtDC.com ? 




Q:www. rbccom ? ^ 






A: www.rbc.com = 
1.2.3.4 




1.2.3.4 
A: www.rbc.com = 




1.2.3.4 A: www.rbc.com = 
142.254.1.143 





TIME 



A: www. rbccom = 
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Random source ports 

Bernstein:Use random src ports as 
entropy 



4 



Q:google.com 



Na 

A:1.2.3.4 
src port: 2220 
TXID: 15824 



A:1.2.3.4 
src port: 2221* 
TXID: 37563 



erver 




Q:google.com 
src port: 8573 
TXID: 12963 




Al.2.3.4 
src port: 2222 
TXID: 23221 



nsl.google.com 



EVIL 
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DJB's hack is still just a hack 



Q:www.rbc.com 
TXID:32768 

SRCPORT:54195 




Q:www.rbc.com 
TXID:32768 
ORT:1025 
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NAT and DNS rebinding 

%"^ Qwww.rbc.com ffl 
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Q:www.rbc.com 
TXID:32768 

SRCPORT:54195 



i 



EndUser 



Nameserver NAT / Firewall 



Q:www.rbc.com 

TXID:32768 
3Rt>PORT:1025 
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IAT and DNS rebinding (2) 



10.1.1.2 



10.1.1.3 



te 



Q: www. evil, com 
► 




A:10.1.1.3 

EndUser Nameserver ^ JiAJ / Firewall 



evil.com 
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irthday Attack on src ports 



♦ 



EVIL 



Q:google.com 

Q:google.com 

Naj 

A:1.2.3.4 
src port: 2220 
TXID: 4524 



A:1.2.3.4 
src port: 2221* 
TXID: 4524 



erven 




Q:google.com 
src port: 14773 
TXID: 49265 

Q:google.com 
src port: 8573 
TXID: 12963 

Q:google.com 
src port: 2222 
TXID: 4524 



A:1.2.3.4 
-re port: 2222 
TXID: 4524 




nsl.google.com 



EVIL 
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•g-Kasphureffs attack (1997) 
caused Bailywick restrictions 



QUESTION SECTION 
Query ID: 54321 
Question: www.ripe.net? 

ANSWER SECTION 





AUTHORITY SECTION 
ripe.net NS ns-pri. ripe. net 
ripe.net NS ns-ext.isc.on 

ADDITIONAL SECTION 



(ttl=FOREVER) 
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What protects our DNS? 






■• Transaction ID (TXID) 
■ • Time To Live (TTL) 
■• Bailywick 
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The Kaminsky Attack 



QUESTION SECTION 

Query ID: 54321 

Question: bogusl2345.www.paypal.com 

ANSWER SECTION 



AUTHORITY SECTION 
bogusl2345.www.paypal.com NS 
www.paypal.com 



If you lose the race, 
try bogusl2346 



ADDITIONAL SECTION 
www.paypal.com A 1.2.3.4 



Overrides cache 



Without source port randomization, this 
only takes about 65535 packets 
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•§— DNS related issues: 
Double Fast Flux 

» Botnets use domains with NS and A 
records with low (eg 3 minute) TTL's 

► Change NS records via Registrar very 

quickly too (hours) 

► This makes them next to impossible to 

shutdown. 
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•§— DNS related issues: 
The Wifi hotspot 

» Captive portals using DNS with mini 
DNS "server" 

» This is so they can serve fake DNS 

This can cause client to cache wrong 
DNS 

Bad implementations break on EDNS 
and DNSSEC (hardcoded bits 
checking) 
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•§— DNS related issues: 
Double Fast Flux 

» Botnets use domains with NS and A 
records with low (eg 3 minute) TTL's 

► Change NS records via Registrar very 

quickly too (hours) 

► This makes them next to impossible to 

shutdown. 
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Where to fix the DNS ? 



■• Authorative nameservers 
■ • Recursive nameservers 
■• Network firewalls and IDS 
*• Applications 

■ 

! • Protect the data or transport ? 
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DNS is critical infrastructure 



Backwards compatible (opt-in) 
Non-invasive or intrusive (drop-in) 
Non-disruptive (no CPU/Bandwidth hog) 
No Protocol changes(we have DNSSEC) 
Preferably no TYPE overloading 
No magic such as untested crypto 
Patent / Royalty free 
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Authorative nameservers 



Upgrade server to allow DNSSEC 
Diversify your infrastructure 



u 



<o> DiG 9. 6. Sal <o> -t ns xelerance.com 
;; global options: printcmd 
; j Got answer: 

;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 57177 
;; flags: qr rd raj QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 



ANSWER SECTION: 
xelerance.com. 
xelerance.com. 
xelerance.com. 

;; ADDITIONAL SECTION: 

nsO.xelerance.nl. 

nsl.xelerance.net, 



WHEN: Sat Ian 31 12:05:29 2009 
MSG SIZE rcvd: 142 



ns2, xelerance.org. 
nsO.xelerance.nl. 
nsl.xelerance.net. 



lack Hat Briefin 



•t 



Network IDS / Firewall 



■ • 



It's patch work (pun intended) 

Does not address the problems 

Cannot make a decision when an attack 
is detected. What to do? Blocking is 
bad (denial of service to yourself) 



Monitor, log and warn. Do not interfere 
Be very careful with DNS load balancers 
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Monitor Unix based DNS 



Unbound DNS answers by return code - by week 



LjJll^J>Su>t|J^ 



25 26 27 28 29 30 31 



□ NOERROR 

■ SERVFAIL 

■ II I - 'II I II 



nswer bogus 

urn rrsets marked bogus 



Cur: 
639.17m 
107.65m 
527.49m 
76.60m 
25.50m 
71.15m 
13.E7m 



Hin: 
224.19m 

21.70m 

223.40m 

7.75m 

0.00 

17.68m 
0.00 



1.50 
219.53m 

1.09 
184.85m 

6.86m 
159.57m 
26.87m 



Max: 
24.27 
6.22 
13.00 
3.37 
776.15m 
6.18 
445.53m 



Last update: Sun Feb 1 11:10:03 2009 
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Monitoring using Cisco 
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Application fixes 



■ • 



So many different applications to fix 

DNS API for applications is poor 

■• Easy to fool: DNS Rebinding or Fast Flux 

■• But let's not build DNS recursive 
nameservers in every application 



(however a good recursive dns server on each host 
is a good solution) 
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•§— The inevitable: 

Fix recursive nameservers 

Port randomization 

Sanitize TTL's 

Use more IP addresses per DNS server 

Harden against bogus size packets 

Harden glue 

Additional queries for infrastructure data 

0x20 
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Birthday Attack protection 



Do not allow multiple queries for the 
same question to be outstanding (AKA 
query chaining) 

(Unbound and PowerDNS support this) 
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Rebinding protection 



Allow to specify IP addresses that may 
never appear in "external" domain 
names 



This way you can ensure 10.1.1.0/24 

would never come in through DNS 

rebinding. 

(supported in Unbound and 

PowerDNS) 



lack Hat Briefin 



•§— The inevitable: 

Fix recursive nameservers 

• RFC 5452 "Measures for Making DNS 

More Resilient against Forged 
Answers" 

• draft-wijngaards-dnsext-resolver-side- 

mitigation 

• draft-vixie-dnsext-0x20 
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Attacks can be detected 



auth ns 



cache ns 
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Attack response #1 



■ • 



At a spoof detection threshold, ignore all 
answers for that query 

Prevents accepting the right forged 
answer 

Also prevents accepting the real answer 
spoofmax=? 

Small value : easy DOS 

Large value: might be too late 
(PowerDNS has spoofmax=20) 
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Attack response #2 



■ • 



At a spoof detection threshold throw 
away the entire cache and start from 
scratch 

Prevents using an accepted forged 
answer 

Small value : easy DOS on the cache 

Large value: might be too late 
(Unbound has spoofmax=10M) 
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Add more NS records? 

'• If you already have at least two or three, 
this does not buy you much 

• Only makes an attack marginally harder 

■ 

• Excessive NS records cause other 
problems (and adds more potentially 
outdated / vulnerable nameservers) 
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Chain your caches |j 

„ (esp. the ones behind NAT) ~ 
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Blacklist IP ranges 



Do not allow certain IP ranges (used 
internally) to be part of an answer from a 
public DNS zone not under our control 



■ • 



This prevents DNS rebinding attacks 



• Example: only allow 10.0.0.0/8 in 
ourdomain.com, nowhere else. 
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^""Hardening infrastructure 

queries 

• Before accepting NS records or A 
records of nameservers, ask at least two 
different nameservers. 

• Before accepting glue records or 
additional data, indepedantly verify these 
with new queries. 

(extra work is only needed once, then we use 
k caching - minimum impact) 
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uouble Fast Flux protection 



Draft-bambenek-doubleflux suggests: 

Replacing the TTL's of NS and A records 
of NS records with TTL=72 hours. 

Llimit Registrar changes to once per 72h 

Recursors and clients should drop NS or 
A of NS with TTL < 12 



lack Hat Briefin 




e 0x20 defense (Paul Vixie) 



You don't need "Td-CaNAdaTRuSt.cOm" 
when you can get ".CoM" 

Fails completely for the root (".") 
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Axel era nee' 

1 The 0x20 defense (Paul Vixie) 



1 



DNS Question: bogusl2345.www.paypal.com? 
Option flags: RD 



j 
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The 0x20 defense (Paul Vixie) 



DNS Question: bogusl2345.www.paypal.com? 
Option flags: RD 



1 

i 



DNS Query ID: 54321 

DNS Question: bOGusl2345. WwW.pAYpaL.Corn 
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The 0x20 defense (Paul Vixie) 



i 



1 

DNS Query ID: 54321 

DNS Question: bOGusl2345.WwW.pAYpaL.Com 


QUESTION SECTION 

Query ID: 54321 

Question: BoGUsl2345.wWW.pAYPal.cOM 

ANSWER SECTION 

AUTHORITY SECTION 
bogusi2345.www.paypal.com NS 
www.paypal.com 




ADDITIONAL SECTION 
www.paypal.com A 1.2.3.4 
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DNSSEC in a nutshell 



■• Show DNSSEC signed zone 
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DNSSEC Lookaside Verification 
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DNSSEC Bonus 



■• Offline secure authenticated wireless 
communication with rendezvous / 
zeroconf / bluetooth 
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www.xelerance.com/dnssec/ 






TLD Production 




1 

■ 
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ccNSO survey Nov 2007 



If you have not implemented DNSSEC, 
are you planning to implement it? 




■YES 85% 
■ NO 10% 
□Unsure 6% 
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ccNSO survey Nov 2007 



If you have not implemented DNSSEC, 
when are you planning to implement it? 



■ 
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□ Percent 
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Wi 


thin 1 year 


2 years 3 years 


No set timeline 
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•§— .gov is signed! 

well, when I made these slides, it was not, 
but now you read it, it should be 



^ DNSSEC for All Top Level .GOV Domains 

^^~ Published: August 29th, 2008 | Category: Security Vulnerabilities 

Last week the Jdget released memoranda M-08-23, titled 

Securing the Federal Government's Domain Name System Infrastructure . The 

document states that all US government top level ,gov domains will use starting 

in January 2009. This is in response to the DNS cache poisoning attack that Dan 
Kaminsky made public a few months ago, 






New Policy 

This memorandum addresses two important issues in following through with the 
existing policy and expanding its scope to address all USG information systems. 

A. The Federal Government will deploy DNSSEC to the top level .gov domain by 
January 2009. The top level .gov domain includes the registrar, registry, and DNS 
server operations. This policy requires that the top level .gov domain will be DNSSEC 
signed and processes to enable secure delegated sub-domains will be developed, 
Signing the to level .gov domain is a critical procedure necessary for broad 
deployment of DNSSEC, increases the utility of DNSSEC, and simplifies lower level 
deployment by agencies, 

B. Your agency must now develop a plan of action and milestones for the deployment 
of DNSSEC to all applicable information systems. Appropriate DNSSEC capabilities 
must be deployed and operational by December 2009. The plan should follow 
recommendations in NIST Special Publication 800-81 "Secure Domain Name System 



*§. 



DNS-DARC Domain Name Sqstem 
Operations, Analysis, and Research Center 

[ Feb 2 2009 meeting information here ] 
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February 3-4, 2009 

Global DNS Security, Stability, and Resiliency Symposium 




GEOffGIA TF(H INFORMATION SECW f.l N'l.E 



& 



ICANN 



^lORGE 



UNIVERSITY 



DNS 
DARC 



[ Feb 3-4 meeting information here] 
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www.govsecinfo.com 



* The Keys to Deploying DNSSEC: Managing and Meeting Your OMB Domain Mame 

Thursday, March 12, 2009 
Session: 8:30AM - 4:30PM 
Presented by: 



MSSK 



mist 

HarinmH tralitatatA 




DNSSEC Development Coordination Initiative 

The DNSSEC Deployment Initiative works to encourage all sectors to voluntarily adopt security measures 
that will improve security of the internet's naming infrastructure, as part of a global, cooperative effort that 
involves many nations and organizations in the public and private sectors. 
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Conclusions (1) 



Update your nameservers, or place them behind new 
nameservers. 

Look into more software then just Bind 

- Unbound, PowerDNS recursor 

Take a fresh look at your deployment, even when 
using firewalls and NAT. DNS will go through those. 

Ditch DNS captive portals and broken DSL routers 



1 
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Conclusions (2) 



• Prepare for DNSSEC 



• Tell your vendor you require DNSSEC on the 
endnode that uses a dhcp obtained DNS forwarder. 
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Questions? 
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